本系列文章以《產品領導人之道》一書為基礎，從人員、產品與流程三個面向，探討 AI 帶來的工作變化，以及產品領導人如何調整團隊的管理、協作與人才培育方式。
昨天談到，AI 讓 PM、設計師與工程師能承接更多種類的工作，團隊也需要重新約定分工與責任。接下來還有一個問題：當每個人都能更快完成手上的工作，整個團隊是否也更快交付？
PM 用 AI 整理需求，設計師快速準備原型，工程師也加快開發。但需求可能還在等待確認，完成的程式碼還沒有人審查，測試發現的問題也需要重新討論。大家都感受到工具帶來的效率，從開始到交付的時間，卻未必有同樣程度的改善。
這時候，產品領導人需要和團隊一起看看：工作究竟停滯在哪裡？原本的合作方式，是否也需要跟著調整？
下圖用管道的寬窄，比喻不同環節的處理能力。當寫程式是主要限制時，改善開發速度有助於工作前進；但如果實作變快，決策與驗證的能力沒有跟上，工作就可能在其他地方累積。
圖：AI 加快部分實作工作後，決策與驗證可能成為新的限制
這不表示決策者或審查者突然變慢了。當前面的產出增加，他們需要處理的內容也可能變多，原本足以應付的安排，現在就不一定夠用。
DORA 在〈Balancing AI tensions〉中，分析了 Google 工程師的開放式問卷回覆，指出使用 AI 省下的部分撰寫時間，會轉移到驗證與審查。作者能快速產生大量程式碼，審查者仍需要理解這些變更、確認它們是否正確。
把這個觀察延伸到產品工作，也值得問：當 PM 更快提出需求、設計師更快準備多個方案，誰來承接後面的確認？我們是否一次產出太多，讓下一個人難以處理？
《產品領導人之道》第 19 章談到，當團隊進展緩慢或無法交付時，主管可以和 PM 一起檢視背後的障礙，包括目標不清楚、團隊缺乏自主性，以及技術問題持續累積。
作者也直接提醒：PM 本身可能成為瓶頸。如果 PM 與團隊相處的時間不足，許多問題就可能停在等待回覆的狀態。當 PM 不在，團隊就無法做決定，也值得留意。
放到 AI 協作的情境，這個問題可能更加明顯。成員能更快提出方案，但如果每一個細節仍要由 PM 確認，或所有決策都得等主管核准，就需要重新檢視授權方式。
主管可以協助 PM 說清楚，哪些事情團隊能自行判斷，哪些情況需要共同討論。對於跨部門優先順序、資源不足等超出團隊影響範圍的障礙，則需要主管出面協調。
要知道工作卡在哪裡，可以挑一項最近完成的功能，和參與成員一起回顧它經過的步驟。除了實際處理的時間，也把等待、交接與退回修改記錄下來。
延續前幾篇的報表資料核對功能：需求整理好之後，是否還在等業務規則確認？開發完成後，是否等了幾天才有人審查？測試發現差異時，又需要回頭找誰釐清？
DORA 的價值流圖指南建議，把工作步驟、等待時間與交接呈現出來，協助團隊形成共同理解。
圖：將工作步驟、等待與交接放在一起，觀察哪些地方反覆出現停留或工作堆積。來源：DORA，〈How to use value stream mapping to improve software delivery〉，依 CC BY 4.0 授權使用。
剛開始不用追求精密數據。先看出哪些步驟只花幾分鐘，哪些地方卻等上幾天，就可能找到值得改善的問題。
不過，單次等待未必代表持續存在的瓶頸。還需要比較其他工作，看看同一個地方是否經常累積項目，以及處理這個問題能否改善整體交付。
看見障礙之後，需要依原因選擇調整方式。
如果工作總在等主管拍板，可以釐清授權與決策條件；如果經常因資訊不足被退回，就讓相關成員提早參與；如果審查持續堆積，可以縮小每次提交的範圍，並安排時間優先處理。
《產品領導人之道》第 18 章提醒，當工作量過大或目標不清楚時，即使善於時間管理，也難以掌控所有工作。作者也建議評估能同時承接多少任務，限制進行中的工作數量。
AI 讓開始一項工作更容易，但團隊仍需要有能力把它完成。有人在等待時，可以先看看是否能協助釐清問題、補足測試或處理審查意見，再決定要不要展開下一件事。《Kanban Guide》也強調控制已開始但尚未完成的工作，並在有能力承接時才開始新工作。
AI 同樣可以協助改善這些環節。例如，在資料使用符合組織規範的前提下，整理阻塞紀錄、彙整待確認事項，或在送審前檢查文件是否有矛盾與遺漏。但整理結果仍需要團隊核對，授權與跨部門協調也需要主管實際投入。
從下一項工作開始，主管可以和團隊一起找出一個反覆出現的等待，選擇有能力改變的地方，嘗試調整。之後再檢查：等待是否縮短？工作是否更容易完成？有沒有增加返工或品質問題？
AI 改變了部分工作的速度，也可能改變團隊需要投入心力的地方。產品領導人需要持續觀察這些變化，協助團隊調整決策、協作與驗證方式。
下次討論 AI 幫團隊省下多少時間時，不妨也一起問：現在最多工作停在哪裡？我們可以先改變什麼？
iThome鐵人賽
看影片追技術